web hosting domain names photo sharing

A RS (BSP) Tutorial

By Gurney, 28th July 2005

Everyone seems to have trouble understanding the RS in EAW, so here goes. A lot of this tutorial is taken from reading "The Black Art of 3D Game Programming" by Andre LaMothe, a book that I brought many years ago, which explains many of the fundamentals of 3D graphics programming. One of the topics covered was the Binary Space Partition.

The BSP is a method that trades initial space and computation for speed of rendering and fast run-time performance. To start with, consider a BSP in 2D. This is the method that games such as Doom used to render their world. Take a top down view of a game world (each of the lines represents a polygon, or a wall in the game world)

Now you can see that if we place the viewer ANYWHERE in the scene it is easy to manually find the order that the polygons should be drawn in.  This is the premise that the BSP algorithm works...that at any point in the game world you can compute the order of polygons.

The algorithm works like this:

• The algorithm selects a polygon in the scene as the partitioning plane (at the moment it doesnt matter which polygon)
• This plane is then used to cut the game space into two sections, in front of the plane, and behind the plane
• The algorithm tests each polygon in the scene against this plane.  If a polygon is cut in half by the plane, then the polygon in this case is split into two new polygons, one in front and one behind the plane.  All the polygons are thus sorted into two lists.  Those BEHIND the partitioning plane and one IN FRONT OF the partitioning plane.
• Next, the algorithm moves to the front list, chooses a polygon as a partitioning plane and repeats the entire process.  It then does the same for the back list.
• This repetition (or recursion) is repeated until the entire list of polygons at each point is reduced to ONE polygon behind and ONE polygon in front   At this point the BSP tree is complete.

The process graphically

First, select polygon 2 as the first partitioning plane.  This gives a front/back list that looks like this:

Since the front side of the list only has one polygon, we cannot split this list any further so we are done on that side, however, on the back side, we still have 3 unsorted polygons.  To break this up we select polygon as the partitioning plane, which further splits the BSP tree to look like this:

ie...
1 is in front of 2
4 is behind 2
3 is behind 4 (and also behind 2)
5 is in front of 4 (and also behind 2)

That, in a nutshell is what a BSP tree is.  It is simply a way of sorting polygons by where they appear in the game world.

Out of curiosity, in the 3DZ converter, this tree would appear as (note that this sequence starts at 0 instead of 1):

[SEQUENCE]
;S000= Back Front
;the first line is the start point of rendering sequence
S000=   1   0
S000= 255 255
S001=   3   0
S002= 255 255
S003=   2   4
S004= 255 255

Drawing this BSP world

To draw this world, we can now use the BSP tree to draw from the furthest polygon to the nearest polygon, thus making sure there are no polygons that show through where they shouldn't.

• We start at our root node, polygon 2.
• The Viewer is BEHIND polygon 2, so we move into the FRONT half-space of polygon 2.
• Since polygon 1 has no children, and we thus cannot move further down this branch of the tree, we draw polygon 1, and move back up the tree by one branch.
• This brings us back to polygon 2, which we now draw
• After drawing polygon 2, we move into it's BACK half-space
• In the back half space, we find polygon 4, which has children.
• Since the viewer is behind polygon 4, we move into the FRONT half-space of polygon 4
• Again, because polygon 5 has no children, we draw it, then move back up the tree
• Now, polygon 4 is drawn, and we move to it's BACK half-space
• Here, polygon 3 has no children, and so it is drawn, and we move all the way back up the tree and get out of it all!

So you can see that with the viewer in this position, the order of drawing is:
1, 2, 5, 4, 3
which, if you think about it, will produce NO overdrawing no matter what angle the viewer is looking at.  VOILA, we have now drawn the scene without worrying about having to check each polygon in real time...a big speed saving!

How does this relate to EAW's RS?

Very easily actually.  EAW's RS system is simply an extension of this algorithm to take into account the fact that the "walls" are no longer all standing straight up....they now appear in 3D.  Because I can't draw well in 3D at all, this is where you have to use your imaginations.  EAW's RS works almost identically, except for one hurdle thrown in by the developers.  Polygons may not be split, as the 3DZ file format has a limit on the number elements.

To start with, a polygon (or element depending on what you call it) is selected - one that does not cut any other polygon in half.  A good choice may be the vertical fin, which would split the aircraft down the middle.  Say for example that we choose the left hand side of the fin, the one that faces port.  If we choose this, then everything on the port side of the aircraft is put into a list as being IN FRONT OF this element, and everything on the starboard side of the element is put into a list as being BEHIND this element.  This fin element then becomes our RS root node.

Now, going by the same algorithm presented above, we move into the list of elements IN FRONT OF the root node.  We can now almost imagine that these are the only elements that exist in the aircraft now.  Again we choose an element that does not cut any other in half, and we sort all the elements in this list as being in front or behind this element.  Again we have two lists, and so we repeat the process, sorting each front list until we have only one element in the front list.  Now we move back up one branch and do the same for that back list.  Basically we move through the whole tree like this, until the whole tree has only one element at the end of each branch.

The tricky bit is that, if at any point in the algorithm we find that have no elements that DO NOT cut another in the list, then we have to move back up one branch and pick a different partitioning plane.  And so on and so on until we get a "good" tree.

The problem of "flashing" elements is caused by the fact that somewhere in the tree, an element has been misplaced.  Thus, when you move around the aircraft and move in front of (or behind) the offending element, EAW still trusts the RS and draws them as told to.  An example might be if you move an element from being right along the centreline of the aircraft (facing right), to being 20 points out to the left.  Before you moved this element, the game knew that if you were on the front side of this element, then you were on the right side of the centreline and could draw its elements accordingly.  But now that it has moved, and you stand, say 10 points to the right of the centreline, you are now listed as being BEHIND the element, and this causes the RS to think that you are on the left side of the centreline.  Hence, EAW draws the aircraft elements in the order that it would have if you had stood on the left side of the aircraft.  And believe me, this causes some wacky results!

Summary

So that is how a BSP tree works.  Simply splitting the world into front and pack "spaces" at each branch.  The EAW RS is very very similar, apart from the fact that it is now in 3 dimensions, and has the restriction of not allowing split polygons.  And that's it really?  Hope it makes things clearer.  If not....read it again until you understand it!  And maybe once again to be sure.  Just don't get it into your head that the RS is incomprehensible....it's not.  It just takes a bit of imagination.